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REMARKS 

Claims 1-16 are currently pending in the application. 

Claims 1-3, 5-6, 8-11, and 13-15 stand rejected under 35 U.S.C. § 102(a), (e) as 
anticipated by U.S. Patent Application Publication No. 2002/0188666 by Lemon et al. 
Applicants traverse on the grounds that these claims are not anticipated by Lemon et al., 
as discussed below. 

Claims 4, 7, 12, and 16 stand rejected under 35 U.S.C. § 103(a) as suggested by 
Lemon et al. in view of U.S. Patent Application Publication No. 2002/0059377 by 
Bandhole et al. Applicants traverse on the grounds that these claims are not suggested by 
Lemon et al. in view of Bandhole et al., as discussed below. 

The Claimed Invention 

The claimed invention provides a system and a method to extend application 
program interfaces to enable human users to interact with conversation-enabled 
applications. (Specification at 1, lines 14-17) The conversation support framework thus 
provided to support long-running human interactions may be implemented with various 
features, including, but not limited to, the following: 

• Small footprint. 

• Automatic generation of views to show messages received in the 
conversation and screen forms to solicit decision input from a user. 

• Plug-and-play support for various on-wire message formats. 

• Plug-and-play support for various incoming and outgoing messaging 
protocols. 

(Specification at 4, lines 1-7) In addition, among other things, an archive format bundling 
conversation policies and message schemas may be employed according to the claimed 
invention. (Specification at 4, lines 9-10) 
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Reiection of Claims 1-3. 5-6. 8-11, and 13-15 Under 35 U.S.C. S 102(a). (e) 

Claims 1-3, 5-6, 8-11, and 13-15 stand rejected under 35 U.S.C. § 102(a), (e) as 
anticipated by Lemon et al. Applicants traverse on the grounds that the rejected claims 
are not anticipated by Lemon et al. In brief, where the claimed invention enables human 
users to interact with conversation-enabled applications, as discussed above, the subject 
matter disclosed by Lemon et al. provides a mechanism for implementing a conversation 
between two services. (Lemon et al., paragraph [001 1]) 

Claim 1 . The Examiner erroneously reads paragraphs [0023], [0027], [0028], and 
[0034] of Lemon et al. as anticipating the following features of independent Claim 1: 

• "[Conversation support means communicating with a human-usable 
interface installed on a user device to support the user's side of a 
conversation with the conversation-enabled applications." (Claim 1, 
lines 4-6) 

• "[Presentation support means communicating with the human-usable 
interface installed on the user device to show the user a state of the 
conversation and options for selection by the user." (Claim 1, lines 7-9) 

• "[D]ata input means installed on the user device by which the user selects 
an available option and fills in message content that conforms with the 
conversation policy in use by the conversation-enabled applications." 
(Claim 1, lines 10-12) 

(Office Action at 3) 

Regarding the requirement of Claim 1 (lines 4-6), "conversation support means 
communicating with a human-usable interface installed on a user device to support the 
user's side of a conversation with the conversation-enabled applications," the Office 
Action asserts that this requirement is anticipated by paragraph [0023] of Lemon et al., 
described in the Office Action as described in the Office Action as teaching that "a 
mechanism provides for a conversation controller," and by paragraph [0027] of Lemon et 
al., teaching to "validate that each message is of an appropriate input document type for 
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the current state of the conversation." (Office Action at 3) However, paragraphs [0023] 
and [0028] discuss conversation controllers (defined at paragraph [0026] of Lemon et al.) 
that handle messages on behalf of "services" (by which is meant "E-Services"; see 
paragraph [0021] of Lemon et al.) and do not discuss the "conversation-enabled 
applications" required by Claim 1. 

Regarding the requirement of Claim 1 (lines 7-9), "presentation support means 
communicating with the human-usable interface installed on the user device to show the 
user a state of the conversation and options for selection by the user," the Office Action 
asserts that this requirement is anticipated by paragraph [0028] of Lemon et al., teaching 
"conversation history," and by paragraph [0034] of Lemon et al., teaching "prompting the 
client for valid input documents." However, paragraph [0028] discusses how a 
conversation controller may track the "state" of a conversation, while paragraph [0034] 
discusses how documents may be formatted in an appropriate format. Neither paragraph 
discusses how a "user device" may "show the user a state of the conversation and options 
for selection by the user," as required by Claim 1 . 

Regarding the requirement of Claim 1 (lines 10-12), "data input means installed 
on the user device by which the user selects an available option and fills in message 
content that conforms with the conversation policy in use by the conversation-enabled 
applications," the Office Action asserts that this requirement is anticipated by 
paragraph [0026] of Lemon et al., teaching "may also invoke appropriate services and/or 
client entry points based on dispatch service description language specifications and 
prompt for valid input document types for a given state of a conversation." 
However, paragraph [0026] of Lemon et al. simply defines a "conversation controller" as 
" a third party service that is capable of facilitating a conversation between two other 
services" and which "may act as a proxy to services and track the state of an ongoing 
conversion based on a conversation definition language specification" as well as "invoke 
appropriate service and/or client entry points . . . thus enabling the services and clients to 
engage in complex interactions with each other." (Lemon et al., paragraph [0026]) 
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Paragraph [0026] does not permit a user to select an available option and fill in message 
content that conforms with the conversation policy in use by the conversation-enabled 
applications, as required by Claim 1 . 

Applicants respectfully submit that Claim 1 should be allowed. 

Claim 2 . The Examiner erroneously reads Figure 6 of Lemon et al. as 
anticipating the following feature of Claim 2: "wherein in the conversation support means 
and the presentation support means are installed on the user device." This is explained as 
attributable to the interpretation that Figure 6 of Lemon et al. "teaches wherein in the 
conversation support means are installed on the user device." (Office Action at 4) 
However, Figure 6 of Lemon et al. shows a computer running a web browser but does 
show a conversation support means installed thereon. Thus, Claim 2 should be allowed. 

In addition, Claim 2 should be allowed as dependent from allowable Claim 1. 

Claim 3 . The Examiner erroneously reads Figure 3 of Lemon et al. as 
anticipating the following feature of Claim 3: "wherein the conversation support means 
and the presentation support means are installed on a remote machine which 
communicates with the user device." This is explained as attributable to the 
interpretation that Figure 3 of Lemon et al. "teaches wherein the conversation support 
means and the presentation support means are installed on a remote machine which 
communicates with the user device." (Office Action at 5) However, Figure 3 of Lemon 
et al. does not show conversation support or presentation support means installed on a 
remote machine, as required by Claim 3, but instead shows how a conversation controller 
manages messages from a client to a service. (Lemon et al., paragraph [0048], discussing 
Figure 3) Thus, Claim 3 should be allowed. 

In addition, Claim 3 should be allowed as dependent from allowable Claim 1 . 

Claim 5 . The Examiner erroneously reads paragraphs [0013] and [0052] of 
Lemon et al. as anticipating the following feature of Claim 5: "wherein the data input 
means prompts the user for decisions and then generates a corresponding screen flow for 
data input and transforms entered data into a format suitable for delivery to the remote 
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location." This is explained as based on the teachings of paragraphs [0013 and [0052] of 
Lemon et al. Paragraph [0013] of Lemon et al., however, provides for transforming 
output documents, such as into a hypertext markup language (HTML) format, while 
paragraph [0052] provides that "the conversation controller . . . may return the message 
back to the client . . . and prompt for next legal input document." Those paragraphs do 
not provide means for prompting a user for decisions, generates a corresponding screen 
flow for data input based on the user input, and transforming entered data into a format 
suitable for delivery to the remote location, as required by Claim 5. Thus, Claim 5 should 
be allowed. 

In addition, Claim 5 should be allowed as dependent from allowable Claim 1 . 

Claim 6 . The Examiner erroneously reads paragraphs [0028] and [0052] of 
Lemon et al. as anticipating the following feature of Claim 6: "wherein said presentation 
support means includes an archive of presentation policies accessed to render messages 
for the user." This is explained as attributable to paragraph [0028] teaching "current sate, 
may need to be tracked." (Office Action at 5) However, paragraph [0028] discusses how 
a conversation controller may track the "state" of a conversation, while paragraph [0052] 
provides that "the conversation controller . . . may return the message back to the client 
. . . and prompt for next legal input document." Neither paragraph provides a 
presentation support means that includes an archive of presentation policies accessed to 
render messages for a user, as required by Claim 6. Thus, Claim 6 should be allowed. 

In addition, Claim 6 should be allowed as dependent from allowable Claim 1 . 

Claim 8 . The Examiner erroneously reads Figure 6 of Lemon et al. as 
anticipating the following feature of Claim 8: "wherein the user device is a personal 
computer." This is explained as attributable to the interpretation that Figure 6 of Lemon 
et al. "further teaches wherein the user device is a personal computer." (Office Action 
at 5) However, while Figure 6 of Lemon et al. shows a computer, the disclosure of 
Lemon et al. does not anticipate every possible invention in connection with which a 
computer may serve as a user device. Thus, Claim 8 should be allowed. 
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In addition, Claim 8 should be allowed as dependent from allowable Claim 1 . 

Claim 9 . The Examiner erroneously reads Figure 3 of Lemon et al. as 
anticipating the following feature of Claim 9: "wherein said presentation support is 
obtained from another system." This is explained as attributable to the interpretation that 
Figure 3 of Lemon et al. "further teaches wherein said presentation support is obtained 
from another system." (Office Action at 5) However,However, Figure 3 of Lemon et al. 
does not show presentation support being obtained from another system, as required by 
Claim 9, but instead shows how a conversation controller manages messages from a 
client to a service. (Lemon et al., paragraph [0048], discussing Figure 3) Thus, Claim 9 
should be allowed. 

In addition, Claim 9 should be allowed as dependent from allowable Claim 1 . 

Claim 10 . The Examiner erroneously reads paragraphs [0023], [0027], [0028], 
[0034], [0056], and [0057] of Lemon et al. as anticipating the following features of 
independent Claim 1 : 

• "[L]oading a selected service device, said service including a policy 
archive and a presentation archive." (Claim 1 0, lines 4-6) 

• "[Installing a conversation policy supporting the selected service." 
(Claim 10, line 7) 

• "[Accessing the policy archive and communicating with the 
human-usable interface installed on the user device to support the user's 
side of a conversation with the conversation-enabled applications." 
(Claim 10, lines 8-10) 

• "[Accessing the presentation archive and communicating with the 
human-usable interface installed on the user device to show the user a state 
of the conversation and options for selection by the user." (Claim 10, 
lines 11-13) 

• "[Prompting user to select an available option and fill in message content 
that conforms with the conversation policy in use by the 
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conversation-enabled applications." (Claim 10, lines 14-15) 
(Office Action at 3) 

Regarding the requirement of Claim 10 (lines 5-6), "loading a selected service 
device, said service including a policy archive and a presentation archive," the Office 
Action asserts that this requirement is anticipated by paragraph [0056] of Lemon et al., 
described in the Office Action as described in the Office Action as teaching that "may 
execute information . . . received from the Internet or other networks," and by 
paragraph [0057] of Lemon et al., described as teaching "these aspects of an 
implementation consistent with the rpesent invnetion are described as being stored in 
memory ... or read from other types." (Office Action at 3-4) However, paragraphs 
[0056] and [0057] discuss the use of a computer in the preferred embodiment of the 
subject matter disclosed by Lemon et al. and do not discuss "loading a selected service 
device" or "including a policy archive and a presentation archive" as required by 
Claim 10. 

Regarding the requirement of Claim 10 (line 7), "installing a conversation policy 
supporting the selected service," the Office Action asserts that this requirement is 
anticipated by paragraph [0023] of Lemon et al., described in the Office Action as 
described in the Office Action as teaching that "a mechanism provides for a conversation 
controller." (Office Action at 3) However, paragraph [0023] discusses the advantages 
of providing "a conversation controller that enables services to carry out an entire 
conversation without the service developers having to implement code to manage 
conversation logic" (the term "services" being understood to be limited to "E-Service"; 
see paragraph [0021]) and does not install a conversation policy supporting a selected 
service, as required by Claim 10. 

Regarding the requirement of Claim 10 (lines 8-10), "accessing the policy archive 
and communicating with the human-usable interface installed on the user device to 
support the user's side of a conversation with the conversation-enabled applications," the 
Office Action asserts that this requirement is anticipated by paragraph [0027] of Lemon et 
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al., teaching to "validate that each mesage is of an appropriate input document type for 
the current state of the conversation." (Office Action at 3) However, paragraph [0027] 
discussed the validation of messages and the optional filtering of prompts by document 
type. Paragraph [0027] does not access a policy archive and communicate with a 
human-usable interface installed on a user device to support the user's side of a 
conversation with conversation-enabled applications, as required by Claim 10. 

Regarding the requirement of Claim 10 (lines 11-13), "accessing the presentation 
archive and communicating with the human-usable interface installed on the user device 
to show the user a state of the conversation and options for selection by the user," the 
Office Action asserts that this requirement is anticipated by paragraph [0028] of Lemon et 
al, teaching "conversation history," and by paragraph [0034] of Lemon et al., teaching 
"prompting the client for valid input documents." However, paragraph [0028] discusses 
how a conversation controller may track the "state" of a conversation, while paragraph 
[0034] discusses how documents may be formatted in an appropriate format. Neither 
paragraph discusses how a "user device" may "show the user a state of the conversation 
and options for selection by the user," as required by Claim 1 0. 

Regarding the requirement of Claim 10 (lines 14-15), "prompting user to select an 
available option and fill in message content that conforms with the conversation policy in 
use by the conversation-enabled applications," the Office Action asserts that this 
requirement is anticipated by paragraph [0026] of Lemon et al., teaching "may also 
invoke appropriate services and/or client entry points based on dispatch service 
description language specifications and prompt for valid input document types for a given 
state of a conversation." However, paragraph [0026] of Lemon et al. simply defines a 
"conversation controller" as " a third party service that is capable of facilitating a 
conversation between two other services" and which "may act as a proxy to services and 
track the state of an ongoing conversion based on a conversation definition language 
specification" as well as "invoke appropriate service and/or client entry points . . . thus 
enabling the services and clients to engage in complex interactions with each other." 
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(Lemon et al., paragraph [0026]) Paragraph [0026] does not permit a user to select an 
available option and fill in message content that conforms with the conversation policy in 
use by the conversation-enabled applications, as required by Claim 10. 

Applicants respectfully submit that Claim 10 should be allowed. 

Claim 11 . The rejection of Claim 1 1 is derivative of the rejection of Claim 2. As 
a result, the foregoing discussion of Claim 2 is incorporated by reference as if fully 
restated herein to show that Claim 1 1 should be allowed. 

In addition, Claim 1 1 should be allowed as dependent from allowable Claim 10. 

Claim 13 . The rejection of Claim 13 is derivative of the rejection of Claim 8. As 
a result, the foregoing discussion of Claim 8 is incorporated by reference as if fully 
restated herein to show that Claim 13 should be allowed. 

In addition, Claim 13 should be allowed as dependent from allowable Claim 1 1 . 

Claim 14 . The rejection of Claim 14 is derivative of the rejection of Claim 3. As 
a result, the foregoing discussion of Claim 3 is incorporated by reference as if fully 
restated herein to show that Claim 14 should be allowed. 

In addition, Claim 14 should be allowed as dependent from allowable Claim 10. 

Claim 15 . The rejection of Claim 15 is derivative of the rejection of Claim 9. As 
a result, the foregoing discussion of Claim 9 is incorporated by reference as if fully 
restated herein to show that Claim 15 should be allowed. 

In addition, Claim 15 should be allowed as dependent from allowable Claim 10. 
Rejection of Claims 4, 7, 12, and 16 Under 35 U.S.C. § 103(a) 

Claims 4, 7, 12, and 16 stand rejected under 35 U.S.C. § 103(a) as suggested by 
Lemon et al. in view of U.S. Patent Application No. 2002/0059377 by Bandhole et al. 
Applicants traverse on the grounds that the rejected claims are not suggested by Lemon et 
al. in view of Bandhole et al. As previously noted, where the claimed invention enables 
human users to interact with conversation-enabled applications, the subject matter 
disclosed by Lemon et al. provides a mechanism for implementing a conversation 
between two services. (Lemon et al., paragraph [001 1]) Bandhole et al. provide a system 
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and method for collaborative computing which: 

• Allocates resources of a dynamic computing environment through a first 
user interface. 

• Shares at least one resource between the first user interface and a second 
user interface. 

• Executes an application on at least one allocated resource using either the 
first or second user interface. 

• Transfers information generated by executing the application to the first 
user interface. 

• Transfers, in response to a command to collaborate with the second user 
interface, the information generated by executing the application to the 
second user interface. 

(Bandhole et al., paragraph [0023]) Thus, a combination of Lemon et al. with Bandhole 
et al. does not result in or suggest the claimed invention. 

Claim 4 . The Examiner has erroneously found the following feature of Claim 4 
to be anticipated by Lemon et al. in view of Bandhole et al.: "wherein the human-usable 
interface is a plugin browser." Recognizing that Lemon et al. do not anticipate Claim 4, 
the Office Action calls on paragraph [0043] of Bandhole et al. to make up for the 
deficiency. (Office Action at 6) That paragraph, however, simply provides that a 
software process employed in conjuction with the subject matter disclosed by Bandhole et 
al. "can be any type of application program, applet, operating system, plug-in, 
user-interface controller, or other process." Bandhole et al. do not suggest every possible 
invention that employs software plug-ins. Neither Lemon et al. nor Bandhole et al. 
suggest that a human-usable interface installed on a user device to support the user's side 
of a conversation with conversation-enabled applications, as in base Claims 1 and 10 
(discussed above), may be implemented as a plug-in, as required by Claim 4. The 
statement that "[o]ne of ordinary skill in the art knows that plug-in' s are employed from 
the Internet for enabling specific functional applications via a browser" (Office Action 
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at 7) constitutes impermissible hindsight as well as an improper assertion of technical fact 
in an area of esoteric technology without support by citation of any reference work. See 
M.P.E.P. § 2144.03, citing In re Ahlert, 424 F. 2d 1088, 1091, 165 U.S.P.Q. 418, 422-21 
(C.C.P.A. 1970). 

In addition, Claim 4 should be allowed as dependent from allowable Claim 1. 

Claim 7 . The Examiner has erroneously found the following feature of Claim 7 
to be anticipated by Lemon et al. in view of Bandhole et al.: "wherein the user device is a 
personal digital assistant." Recognizing that Lemon et al. do not anticipate Claim 7, the 
Office Action calls on paragraphs [0030] and [0041] of Bandhole et al. to make up for the 
deficiency. (Office Action at 7) Those paragraph, however, simply provide for the use of 
a personal digital assistant in connection with the subject matter disclosed by Bandole et 
al. However, simply because Bandhole et al. foresee the use of personal digital assistants 
in connection with the subject matter of their disclosure, it does not follow that every 
possible invention capable of being implemented with a personal digital assitant is 
suggested by Bandhole et al. Neither Lemon et al. nor Bandhole et al. suggest that a user 
device supporting the user's side of a conversation with conversation-enabled 
applications, as in base Claims 1 and 10 (discussed above), may be embodied in a 
personal digital assistant, as required by Claim 7. 

In addition, Claim 7 should be allowed as dependent from allowable Claim 1 . 

Claim 12 . The rejection of Claim 12 is derivative of the rejection of Claim 7. As 
a result, the foregoing discussion of Claim 7 is incorporated by reference as if fully 
restated herein to show that Claim 12 should be allowed. 

In addition, Claim 12 should be allowed as dependent from allowable Claim 11. 

Claim 16 . The rejection of Claim 16 is derivative of the rejection of Claim 4. As 
a result, the foregoing discussion of Claim 4 is incorporated by reference as if fully 
restated herein to show that Claim 16 should be allowed. 

In addition, Claim 16 should be allowed as dependent from allowable Claim 10. 
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Conclusion 



In view of the foregoing, Applicants submit that Claims 1-20 are in condition for 
allowance. The Examiner is respectfully requested to pass the above application to issue. 
The Examiner is invited to contact the undersigned at the telephone number listed below, 
if needed. 

Applicants hereby make a written conditional petition for extension of time, if 
required. Please charge any deficiencies in fees and credit any overpayment of fees to 
Applicants' Deposit Account No. 50-0510 (IBM Corporation). 



Whitham, Curtis Christofferson & Cook, P.C. 
1 1491 Sunset Hills Road, Suite 340 
Reston, Virginia 20190 
Tel. (703) 787-9400 
Fax. (703) 787-7557 




fitted, 



Michael E. Whitham 
Registration No. 32,635 



